ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group97a.txt/000046_icon-group-sender _Mon Feb 24 14:30:06 1997.msg

Internet Message Format | 2000-09-20 | 6KB

Received: by cheltenham.cs.arizona.edu; Tue, 25 Feb 1997 08:35:45 MST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 24 Feb 1997 14:30:06 -0600
To: Jan Galkowski <[e-mail]>, [e-mail]
From: Chris Tenaglia <[e-mail]>
Subject: Re: What's the biggest Icon program you've written?
Errors-To: [e-mail]
Status: RO
Content-Length: 4952

At 10:19 AM 2/24/97 -0500, Jan Galkowski wrote:
>Marc Espie wrote:
>>
>> In article <[e-mail]>,
>> Jan Galkowski  <[e-mail]> wrote:
>
>[snip]

>> I've got into the main pitfall of Icon: forgetting about failure.
>> writing stuff such as i <- value & function(i)
>> forgetting that function(i) was not returning anything, or using
>> suspended generators, and having them resumed and backtracking and... well,
>> ending up with the assignment to i being cancelled where it was not
>> intended.
>
>    This is interesting.  I would have thought notions of success and failure,
>a la logic programming, was a big reason for using Icon.  It is bound to have
>serious impacts upon one's design and programming styles if one plans to
use it.
>
Failure is part of the language design. It DOES impact design.
But I think that it's a positive thing. I think it's elegant, actually,
that one could make use of "nothing". It's part of everything in
this language fitting together so well.

>>
>> The biggest problems I've run into are some limitations of Icon.  There are
>> no modules, no import/export mechanism for big projects.
>
>    IMO, I'm not sure these are as much limitations of Icon as taking where it
>hasn't received much use or wasn't intended to be used.  I can't really answer
>that, of course.  I feel it is someplace where it would be useful to have some
>support.  But I don't know whether Idol-like solutions are right.  In fact, I
>tend to doubt they are.  And I feel I don't want to clutter up the presently
>pretty language with other than more built-ins.  That is, I wouldn't want to
>change the syntax in any way that would require, for instance, some declarative
>sugar on every procedure.
>
>    And also, it's not clear that ways of controlling and organizing many small
>pieces of text, each with a local scope, belong in a programming language.  I
>am in favor of something being there which facilitates this, but that is hardly
>a universal or a compelling view.
This hasn't affected my developments. I've tried to keep the modules
small and well documented. My biggest headache came from the VMS
implementation. Up till V8.6 it was rock solid. Then V8.7 came out with
X-windows stuff and things began to fall apart. Then it couldn't handle
char(255)  (aka \xff). Now I couldn't get it to recompile successfully
on the Alpha AXP. I gave up on the VMS side.

>[snip]
>
>>
>> I've somewhat stopped trying to `sell' Icon to anybody... about the time
>> I stopped selling the Amiga to anybody, for mostly the same reasons.
>
>  I didn't meaning "selling" in the evangelical sense but, rather, in a
business
>case to immediate management.  And, if I may read into your post, do you
>mean you feel Icon is as dead as the Amiga is?
I don't ask anymore either. I just do it, do it well, document it, and I'm
glad it holds up. I'm also open to training any coworker who wants in.

>
>>
>> There are some arresting problems.
>> The fact that Icon is supported by a rather small development team (for
>> instance, compiler work is stopped) is a problem.
>
>   I respectfully disagree.  If anything characterizes Icon's implementations,
>IMO, it is that elusive attribute called "coherence".  Its opposite is the MS
>treatment of a software megolith like Visual Basic.
That hasn't affected me. After the first year, and having the book
I became pretty self sufficient. It hasn't needed oodles of patches
and if somthing works well enough, a lot less support is needed.

>[snip]
>
>> There is such a wealth of perl programmers/perl development these days that
>> is very difficult to match with Icon. For instance, the text editor nvi
>> does procure an interface to perl...
>>
>    The "effort threshold" to acceptance of Icon is its innovative concepts.
>Without these, such as its ideas on elevating success and failure, it would not
>be Icon.  But these new ideas are its raison d'etre, not an obstacle.
I agree.
Another side note: I've heard the common complaint that Icon
doesn't have enough system interfaces (like perl does). At least
in my applications, I'm not really interesting in the guts of the
OS, but rather files, which I think is Icon's forte. I kind of view
deep system access as a liability, that makes it that much easier
to mess things up (even by accident) and crash the system.
Icon insulates us (and our apprentices) from those dangers.
I have never yet found myself needing or wanting that deep
of access for icon. (although I did alot with assembler many years
ago).

>--
> Jan Theodore Galkowski,
>    Developer, tool & numerical methods elf
> Digicomp Research Corporation,
> Ithaca, NY 14850-5720
>
>

Chris Tenaglia (system manager)         |       [e-mail]
Medical College of Wisconsin            |
8701 W. Watertown Plank Rd.             |      Ce que vous voyez est
Milwaukee, WI 53226 [phone]       |      Ce que vous obtenez !